There's a longer thread about that here - https://developer.apple.com/forums/thread/650876. There you'll find a few posts with possibly helpful examples.

Hmm. I wrote a mock app that has multiple NavigationLinks and I can read an EnvironmentObject down multiple layers. However, I'm running this in Xcode 11.5, on the simulator running iOS 13.5. So if you're not able to do this, perhaps it's a bug in Xcode 12 and not iOS? Or Maybe you're running it from the Xcode 12 beta on an iOS 14 device, and you're hitting an iOS 14 beta bug? import SwiftUI struct ContentView: View { // PassedObject is just a class that is an ObservableObject with one @Published property, name: String // it is injected into the environment in the SceneDelegate     @EnvironmentObject var nameObject: PassedObject     var body: some View {         NavigationView{             VStack {                 Text("Hello, \(nameObject.name)!")             NavigationLink(destination: SecondView()) {                 Text("Click!")             }.buttonStyle(PlainButtonStyle())             }         }     } } struct SecondView: View {     var body: some View {         VStack {             Text("Second View!")             NavigationLink(destination: ThirdView()) {                 Text("Click Again!")             }.buttonStyle(PlainButtonStyle())         }     } } struct ThirdView: View {     var body: some View {         VStack {             Text("Third View")             NavigationLink(destination: FourthView()) {                 Text("Once More!")             }.buttonStyle(PlainButtonStyle())         }     } } struct FourthView: View {     @EnvironmentObject var passedName: PassedObject // Reading from the environment here, despite multiple views in-between     var body: some View {         VStack {             Text("Hello \(passedName.name)")             TextField("Change Name", text: $passedName.name) .textFieldStyle(RoundedBorderTextFieldStyle())         }     } }

I think a few people have suggested something similar to what m2ike suggested: MainView().environment(\.managedObjectContext, PersistentStore.shared.persistentContainer.viewContext) It certainly works to read the viewContext from the PersistentStore. However, speaking only for myself, I'm looking for a way to create a wrapper class around the NSPersistentContainer instance that can be passed around the entire view hierarchy, and not only pass around the viewContext. The reason for this is that I want custom methods for saving, creating new entity objects, fetching specific sets entities, etc. In order to do this, there seem to be at least 4 different approaches: Pass the context through the \.managedObjectContext environment key, and recreate all the save, creating, fetching functions wherever you read the context [Obviously this would be a silly approach, with a lot of duplicated code prone to errors] Create a helper class that contains all the save, creating, fetching functions, and pass that into the environment, while separately passing around the viewContext as described above. [This works, but it would be better to pass the context and the helper functions together]. Pass the store instance into the environment as an environmentObject, but not using the \.managedObjectContext key [This seems like it should work, but the app kept crashing when it tried to read the fetched objects from the store - most likely I was doing something wrong.] Something like what AlbertUI proposed, but with some (currently unknown?) tweak to address the problem that the \.managedObjectContext key requires an NSManagedObjectContext object instead of a store singleton.

My understanding is that the key differences between @ObservedObject and @StateObject relates to ownership of the object and how likely it is for the object to be recreated. For example, if you have a view that creates an @ObservedObject var test = Test(), every time that view is redrawn (which might be many times), it will recreate a new instance of Test. If you have a view that takes an @ObservedObject as an initialized property like struct Tester: View { @ObservedObject var test: Test var body: some View { ... } } Then the test instance won't be recreated each time the Tester view is redrawn, but you're then dependent on whatever view owns the Test object to hold onto it. @StateObject avoids much of those issues. struct Tester: View { @StateObject var test = Test() var body: some View { ... } } In that example, @StateObject tells SwiftUI to hold onto the value of test, even if the view is redrawn repeatedly.

@AlbertUI Hmm, I tried your approach, and tried passing PersistentStore.shared into the environment var body: some Scene {         WindowGroup {             MovieList() .environment(\.managedObjectContext, PersistentStore.shared) } } But I got an error saying that it could not convert type PersistentStore to expected argument type NSManagedObjectContext. Any ideas? PersistentStore.shared would be type PersistentStore, which wouldn't work if you need to pass in a NSManagedObjectContext, right?

I think the answer to both of your questions is pretty similar. In iOS 13, I've used the Scene Delegate to hold my source of truth for things like my model. For example, in the willConnectTo function in SceneDelegate, when the ContentView is created, I've simply added in my managed object context (when using Core Data): let contentView = ContentView().environment(\.managedObjectContext, context) I've done similar for injecting observable objects into my environment using .environmentObject In iOS 14 there's no SceneDelegate, but we can do something similar when the ContentView in instantiated. var body: some Scene {         WindowGroup {             ContentView().environment(\.managedObjectContext, context)     } } So I think that's what they mean when they say you can put the source of truth on a view inside a WindowGroup. Also, I'm not sure I know what you mean by WindowGroup > Window > View. I think the hierarchy is App > Scene > View. WindowGroup is just a primitive version of a scene. https://developer.apple.com/documentation/swiftui/scene

Thanks @AlbertUI. If I'm understanding your code correctly you're putting the entire PersistentStore class singleton instance into the managedobjectcontext key path, as opposed to only the context? So I assume you can have all manner of helper methods in your PersistentStore class and call those through persistentStore.shared.saveNewObject(), persistentStore.shared.fetchObjects(named: "foo"), etc? When I was playing around earlier, I was only storing the context under the managedobjectcontext key path, but I never thought it would be possible to put the whole wrapper class into the key path...

Super helpful @mtsrodrigues. Is it possible to abstract the persistent container behind a store class that handles adding new items, saves, deletes, etc., and pass that into the environment and update the UI based on changes to the store? I've been trying to make such a thing work with SwiftUI, but have so far been running into lots of roadblocks (but it's probably more my lack of experience with CoreData, than anything else).

Unclear if related at all, but now when I try to log into Feedback Assistant, I end up in an endless log-in loop. Enter username and password, do the two factor authentication, see the spinner, then back to the log-in screen... repeat, repeat, repeat.

Thanks - I created a Feedback/Radar, here: FB7788744

I've posted new threads and there have been responses to those threads, but I haven't seen any way to get notifications for those responses. This is a feature that would be very helpful.

@kmt901 Also new additions to SwiftUI are backwards capable with iOS 13 so you won't have to necessarily bump up your deployment target to iOS 14 To respond to @Smithers question, this does not mean that you can use iOS 14 SwiftUI features in an iOS 13 app (hence why they are marked 14+ only). I think @kmt901 is correct that SwiftUI methods that work in iOS 13 still work in iOS 14. By contrast, from what I heard when Swift moved from Swift 1 to 2 to 3, each time they changed lots of key things, so that apps built using one version broke in the next one. And luckily that isn't happening with SwiftUI this year.

@D-hops: I'm in the same situation. I'm working on finishing up my first app for iOS 13 and have wondered about what is supposed to be done with a new iOS comes out. This is answering some questions, but I'm not familiar with git (I assume GitHub) or branches of code. Can anyone point me in the direction of how to use GitHub with Xcode? And how to branch code... :D I can't include links, but Ray Wenderlich has a tutorial on using Xcode 9 with git, which is slightly out of date, but I could figure it out from there. Atlassian also has some general git tutorials.

Thanks @Developer Tools Engineer! You can also use 'if #available' in your code to make sure new code only runs on iOS 14. Are there any good resources you recommend for using if #available? I've never used that before and don't know where to start. And for testing my app with iOS 14, I'm not sure I follow this: When building with Xcode 12, you also use the iOS 13 SDK for your iOS app but you still deploy to iOS 13 if that's your deployment target. Is selecting the iOS 13 SDK a setting that I need to select within Xcode 12 when I build?

I had this same issue. I suspect, although I'm not sure at all, that it had something to do with trying to install the app on my device wirelessly when on a fairly weak wifi network. Something seemed to get corrupted and then it wouldn't work even when plugged in over USB.In any event, I removed the app from my device, I removed my device from Xcode, then I did a force restarton my device, and repaired my device with Xcode. Then it subsequently worked and haven't had any issues since then.